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Results of the Election for the 
USENIX Association Board of Directors 

The results of the elections for Board of Directors of the USENIX Association for 1988- 


1990 are as follows: 




Elected: 





President: 

Alan G. Nemeth 

592 

+ 

45 Abstentions 

Vice President: 

Deborah K. Scherrer 

594 

+ 

43 Abstentions 

Secretary: 

Rob Kolstad 

579 

+ 

57 Abstentions 

Treasurer: 

Stephen C. Johnson 

585 

+ 

49 Abstentions + 1 


Marshall Kirk McKusick 

423 




Michael D. O’Dell 

399 




John S. Quarterman 

394 




Sharon Murrel 

296 




Not elected: 


David A. Yost 293 

Eugene H. Spafford 292 

Robert A. Morris 170 

Waldo M.Wedel 132 

Charles H. Sauer 121 

Total number of ballots: 654 


There was one write-in vote for Peter Salus as Executive Director. 

Peter H. Salus 
Executive Director 
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San Francisco Conference June 20-24 


See You in San Francisco 

Get your face saved! 

Reception in the Exploratorium! 

Tutorials and technical sessions 
for Children of all ages! 


Best Student Paper 

The Program Committee for the San 
Francisco Technical Conference has named 
Ben Zorn, University of California, Berkeley, 
the author of the best student paper at the 
conference. Zorn’s paper, “A Memory Alloca¬ 
tion Profiler for C and Lisp Programs,” will be 
delivered at 4 pm on Thursday, June 23. 


Fifth Annual Computer GO Tournament 


The fifth annual USENIX Computer Go 
Tournament and Championship will be held 
on Wednesday, June 22, during the USENIX 
conference in San Francisco. All interested 
parties are invited to submit programs. The 
tournament rules will be essentially those 
established for the first USENIX Computer Go 
Tournament. 

Sequent Computer will provide a 
Symmetry S81, which results in two major 
changes in the rules for this year. First, 
program time will be measured by clock time, 
not CPU time. This allows entrants to take 
advantage of the Sequent’s multiple proces¬ 
sors. Second, contestants may provide their 
own hardware such as IBM PCs; such entries 
must communicate with the Sequent machine 
over a 9600 baud RS-232 link, using the usual 
ASCII protocol to talk to the referee. 


Conference attendees may bring programs 
to submit with them as long as they get in 
touch with Rob Pike no later than noon on 
June 21 (preferably earlier). He can be 
reached through the Conference Office. Those 
unable to attend the conference who would 
like to enter programs can do so by sending a 
compilable source to one of the addresses 
below. 

Comments, programs, or requests for 
more information (including details of the 
Sequent computing environment) can be sent 
via electronic mail to UUCPlresearchlrob or 
ARPA!rob@att.com. U.S. Mail should be sent 
to: 

Rob Pike 

Bell Labs 2C524 

Murray Hill, NJ 07974 USA 


1988-89 USENIX Scholarship Winner 


Peg Schafer of the MIT Media Lab will be the recipient of the 1988-1989 USENIX Scholarship. 
Schafer is conducting research into the shape representations used by people with the intention of 
using these representations in computer graphics and machine vision. 
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Call for Papers 
UNIX Security Workshop 

Marriott Hotel 
Portland, Oregon 

August 29-30, 1988 


Matt Bishop is chairman for the UNIX 
Security Workshop to be held in Portland, OR, 
on Monday and Tuesday, August 29th and 
30th, 1988. This workshop will bring together 
researchers in computer security dealing with 
UNIX and system administrators trying to use 
UNIX in environments where protection and 
security are of vital importance. It is believed 
these people battle many of the same problems 
repeatedly and can share their unique solu¬ 
tions to some problems in order to avoid 
duplication of effort in making UNIX secure 
enough for their needs. It is intended that 
each participant will present briefly unique 
attributes of his/her environment and/or 
research and contribute a short (five minute) 
discussion (and paper) detailing some solution 
from their environment or work. 

Some topics to be considered include: 
password security (password file integrity, 
enforcing choice of a safe password, spotting 
and handling crackers), network security 
(problems arising from logins over an 
unprotected ethernet, containing a break-in to 
one machine in a networked environment), file 
system security (auditing packages, security in 
an NFS environment), new designs to obtain 
C-level (or better) certification, making existing 
UNIX systems more secure, and locating and 
fixing UNIX security problems. 


Workshop Format 

This gathering will follow a “workshop” 
format rather than a “paper presentation” 
format. Each participant submits (electroni¬ 
cally, to the address below) a one or two page 
single-spaced summary describing a solution to 
some problem from the topics above (or some¬ 
thing equally interesting/important). Use the 
first paragraph to describe the properties of the 
environment and anything that makes it 
unique (e.g., distributed, large, supercomput¬ 
ers, mixed-vendors). Follow with a description 
of the problem and a description of the solu¬ 
tion (detailed enough that fellow researchers 
and administrators can implement or use it). 
Also, please include with your submission a set 
of five (or so) topics that you’d like to hear 
about. It is possible that some participants 
will not present their papers at this first 
workshop. 

The workshop chairman will collate the 
papers to schedule sessions which have 
appropriate audiences. It is anticipated that 
some sessions will include all 60-100 
participants; some may require breaking into 
smaller groups. Send your submissions to 
Matt Bishop by noon EDT July 1, 1988. 

For further details on the workshop: 

Matt Bishop 

Dept, of Mathematics and Computer Science 
Bradley Hall 
Dartmouth College 
Hanover, NH 03755 

(603) 646-3267 

(ihnp4,decvax)!dartvax!bear!bishop 

bishop%bear.dartmouth.edu@relay.cs.net 
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Call for Papers 

Workshop on UNIX and Supercomputers 

Westin William Penn Hotel 
Pittsburgh, Pennsylvania 

September 26-27, 1988 

A large number of supercomputers are now or will in the future be running UNIX as 
their primary operating system. This is the first workshop to consider the general problems 
of running UNIX on supercomputers, and will cover topics both practical and abstract. 
Areas of specific interest include but are not limited to: 

Systems administration 
Archiving 
Scheduling 
File systems 

Networking and network protocols 
Job batching systems 
Monitoring performance/parallelism 
Programming languages and environments 
Fast file I/O 

Shared memory management 
IPC 

Very large files 
Checkpoint-restart 

The workshop will include both shorter presentations and full-length papers, and there 
will also be tours of Pittsburgh Supercomputing Center and Westinghouse Energy Center 
facilities and a reception at the Pittsburgh Supercomputing Center. Workshop proceedings 
will be available at the Workshop. 

If you are interested in presenting either a full paper or a brief discussion of your 
current work, please send an abstract of your paper or presentation to Melinda Shore by 
July 15, 1988. If you are sending your submission by US Mail, please send three copies. All 
submissions will be acknowledged. 

Program Co-chairs: 

Lori Grob 

NYU Ultracomputer Research Lab 
715 Broadway, 10th Floor 
New York, NY 10003 

(212) 998-3339 
grob@lori.ultra.nyu.edu 


Melinda Shore 

Pittsburgh Supercomputing Center 
4400 Fifth Avenue 
Pittsburgh, PA 15213 

(412) 268-5125 
shore@reason.psc.edu 
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Call for Papers 
C++ Conference 

Denver, Colorado, October 17-21, 1988 


USENIX is pleased to host its first full 
C++ conference in Denver, Colorado, Monday 
through Thursday, October 17-20. A one-day 
limited-enrollment implementor’s workshop 
will follow the conference on Friday, October 
21 . 

Papers are solicited on all aspects of C++, 
including: 

applications 

libraries 

new or improved implementations 

programming environments 

case studies 

We intend this conference to be interest¬ 
ing to a broad range of C++ users and poten¬ 
tial users. Even if you have never written a 
C++ program, you will probably be able to 
learn enough from the tutorials to follow the 
technical sessions. 

Tutorials, Monday and Tuesday 

The tutorial program is ideal for people 
who have been thinking about using C++ but 
haven’t had the opportunity to learn it. In 
addition, we expect to cover selected advanced 
topics for people who are already using C++. 

Please contact the program chair if you 
are interested in giving a tutorial or have a 
topic you would particularly like to see 
covered. 

Technical sessions, Wednesday and Thursday 

One characteristic of C++ that stands out 
is the diversity of its applications and users. 
They range from microcomputers to large 
systems, from graphics and databases to real¬ 
time process control, from single-programmer 
efforts to large projects. 

The technical sessions will present a 
cross-section of this diverse and rapidly grow¬ 
ing community. 

Implementor’s Workshop, Friday 

This small workshop is intended for peo¬ 
ple who are actively involved in C++ imple¬ 
mentation. The workshop fee covers hotel 


accommodations for Thursday and Friday 
nights, meals through Friday lunch, and 
round-trip transportation leaving Denver after 
the main technical sessions and returning 
Saturday morning. 

The workshop is primarily for speakers at 
this and last year’s C++ meetings. If space 
permits, a few others will be admitted. If you 
don’t want to speak at the conference, but 
wish to attend the workshop, let us know and 
submit a paper or abstract of your relevant 
work just as you would if you were interested 
in speaking at the conference. Details about 
the workshop will be sent with acceptance 
notices. 

Program Committee 

Andrew Koenig, AT&T, chair 

Keith Gorlen, National Institutes of Health 

Mark Linton, Stanford University 

Richard Myers, Apple Computer 

Peggy Quinn, AT&T 

Mark Rafter, University of Warwick 

Michael Tiemann, MCC 

Extended abstracts (2-4 pages) or papers 
(9-12 pages) must be received, either electroni¬ 
cally (preferred) or on paper, by Tuesday, June 
14 . Authors will be notified of acceptance by 
August 1 and must submit a full paper 
electronically (preferred) or in camera-ready 
form by August 30. 

Send all submissions to Peter H. Salus at 
usenixlpeter or the Association office. 

Direct all queries about the technical 
program to: 

Andrew Koenig 
Room 4N-R12 
AT&T Bell Laboratories 
184 Liberty Comer Road 
Warren, NJ 07060-0908 

ark@europa.att.com or (attmail,research)!ark 
+ 1 201 580 4127 (FAX) 

+ 1 201 580 4883 (last resort) 
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Call for Papers 

Workshop on Large Installation Systems Administration 

Monterey, California 
November 17-18, 1988 

In light of last year’s successful workshop on Large Installation Systems Administration, 
Alix Vasilatos will again be chairing a workshop on this subject in Monterey, CA on Thurs¬ 
day and Friday, November 17th and 18th, 1988. There is demonstrable benefit in bringing 
together system administrators of sites with 100 or more users (on one or more processors) 
to compare notes on solutions that they have found for a variety of common problems. 
These include but are not limited to: 

Large file systems (dumps, networked file systems) 

Password file administration 

Large mail system administration 

USENET/News/Notes administration 

Heterogeneous environments (mixed vendor and/or version) 

Load control and batch systems 
Monitoring tools 

Software release to multiple systems 
Output device management 

We are particularly interested in technical solutions to problems involving changes 
which directly affect users. 

The workshop will focus on short papers and presentations. Please submit (electroni¬ 
cally, to alix@athena.MIT.EDU) a one or two page single-spaced summary describing the 
solution to a problem. Include a description of the unique characteristics of the site, an out¬ 
line of the problem, and a description of the solution (detailed enough that fellow adminis¬ 
trators can implement it). Workshop proceedings will be available at the workshop. 

The deadline for submissions is September 15, 1988. For further details about the 
workshop, contact: 

Alix Vasilatos 
MIT Project Athena 
E40-357 

1 Amherst Street 
Cambridge, MA 02139 

alix@athena. MIT.EDU 
(617) 253-0121 

For details about registration, contact the USENIX Conference Office. 
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EUUG Autumn Conference 


Portugal 

October 3-7,1988 


The Autumn ’88 European UNIX systems User Group Technical Conference will be 
held in southern Portugal. Technical tutorials will be held on October 3 & 4, followed by 
the three day conference. 

The theme of the conference is “New Directions for UNIX.” Papers are expected on a 
wide variety of topics. 

For further information about this and future EUUG events, contact the Secretariat. 


Secretariat 
EUUG 
Owles Hall 
Owles Lane 

Buntingford, Herts. SG9 9PL UK 
Phone: (+44) 763 73039 
Fax: (+44) 763 73255 (G2) 

Email: euug@inset.uucp 


Tutorial Officer 
Neil Todd 
1ST 

60 Albert Court 
Prince Consort Road 
London SW7 2BH UK 
Phone: (+44) 1 581 8155 
Fax: (+44) 1 581 5147 (G3) 

Telex: 928476ISTECH G 
Email: neil@ist.co.uk 


Programme Chair 
Peter Collinson 
Computing Laboratory 
University of Kent 
Canterbury, Kent CT2 7NF UK 
Phone: (+44) 227 764000, x7619 
Email: pc@ukc.ac.uk 


[This abstract was inadvertently ommitted from the Proceedings of the Fourth Computer Graphics 
Workshop, 1987 -PHSJ 


Addendum to the Computer Graphics Workshop Proceedings 


CAD_CLOTHES: A First Step in the Computerization of Garment Pattern-Making 


Alice Jackson 

Department of Computer Science 
University of Arkansas at Little Rock (UALR) 
Little Rock, AR 72204 


Although the garment-making industry is 
very labor intensive, only a few tasks in the 
production process have been computerized in 
the United States. This study is a first step in 
the creation of a computer system to automate 
the design and production of garment patterns. 
The system can be useful to both the commer¬ 
cial garment manufacturer and the manufac¬ 
turer of patterns for the person who sews at 
home. 

Garment patterns are created in three 
ways: draping, drafting, and flat pattern 
design. Flat pattern design is the one used 


most frequently in the volume apparel 
industry. The first step in flat pattern design is 
the creation of a foundation pattern (called a 
“sloper”). The sloper is then modified to 
create a pattern that can be used to cut fabric 
in order to sew a garment. 

CAD_CLOTHES accepts body measure¬ 
ments from input screens to be used to 
calculate sloper. The system produces both 
the sloper pattern pieces themselves and data 
to pass to subsequent stages of the production 
process. In addition, one of the modules in the 
system measures the computer image to verify 
the accuracy of the results. 
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[This paper was inadvertently omitted from the Winter 1988 Conference Proceedings -PHSJ 


LOCK/ix: An Implementation of UNIX for the LOCK TCB 


Mark A. Schaffer 


Geoff Walsh 


Honeywell 

Secure Computing Technology Center 
2855 Anthony Lane South - Suite 130 
Minneapolis, MN 55418 
(612) 782-7134 


R&D Associates 
4640 Admiralty Way 
Marina del Rey, CA 90295 
(213) 822-1715 


ABSTRACT 

The Logical Coprocessing Kernel (LOCK) is a Trusted Computing Base (TCB) that is 
designed to meet and exceed the requirements for a Class A1 secure system. This paper 
describes the results of a study that determined how to port the UNIX System V Operating 
System to the LOCK TCB, while maintaining maximum compatibility with the System V 
Interface Definition (SVID) [SVID86]. 


1. Background of the Problem 

Over the years, UNIX has gained 
widespread acceptance as the de facto standard 
Operating System (OS) within the U.S. 
Government and private industry. During the 
same time that UNIX has gained in popularity, 
a demand for secure computing systems has 
developed. Recently, the demands for these 
two technologies have created a demand for 
secure UNIX systems within the user 
community. 

To meet the demand for secure UNIX 
systems, we decided to port UNIX to LOCK 
rather than develop a new OS. This is very 
appealing from a practical point of view 
because a large amount of portable UNIX 
applications already exists. 

1.1. Background of the Solution 

Traditional approaches to providing 
Multi-Level Secure (MLS) computing systems 
have emphasized implementing software 
security kernels that run in the target 
processor’s privileged mode. In some cases, 


security has been provided by redesigning the 
OS. These purely software approaches to pro¬ 
viding multi-level security have four primary 
disadvantages: 

1. DECREASED ASSURANCE since a 
software malfunction could cause total security 
failure, 

2. DECREASED PERFORMANCE to usually 
unacceptable levels because of the high over¬ 
head incurred by performing the security 
access checks in software, 

3. LOSS OF EXISTING APPLICATION 
SOFTWARE because of the extensive redesign 
of the operating system, and 

4. INABILITY TO FUNCTIONALLY 
ENHANCE the OS without requiring expensive 
and time-consuming re-verification and 
revaluation [SAYD87], 

The LOCK TCB is a MLS computing system 
currently being prototyped at Honeywell 
Secure Computing Technology Center. It has 
been designed to meet and exceed the require¬ 
ments for a Class A1 system as defined in the 
DoD Trusted Computer System Evaluation 
Criteria (the Orange Book) [TCSEC85]. 


This effort has been supported by National Computer Security Center contract MDA904-87-C-6011. 
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LOCK is the third phase of a continuing 
project previously called the Secure Ada 
Target (SAT), which was started by Honeywell 
in 1982. The first phase of the SAT program 
(SAT-0) resulted in a high-level requirements 
specification [HONE83]. The second phase 
(SAT-I) resulted in an intermediate 
specification [HONE86]. The third phase 
(SAT-II), renamed LOCK, will result in a 
detailed design specification and MLS mini¬ 
computer prototype in 1990 [SAYD87]. 

1.1.1. The LOCK Solution to Multi-Level 
Security 

The LOCK system takes a hardware- 
oriented approach to providing a MLS comput¬ 
ing system which should enable the system to 
overcome the disadvantages associated with 
purely software approaches. 

The security policy of the system is 
enforced by a physically separate, multi¬ 
processor, coprocessing unit called the 
System-Independent, Domain-Enforcing, 
Assured, Reference Monitor (SIDEARM). The 
SIDEARM has its own processors, memory, 
and mass storage. All security-related data is 
stored on the SIDEARM mass storage unit. All 
access decisions and computations are 
performed by the SIDEARM. 

The physical separation of the protection- 
critical from the non protection-critical ele¬ 
ments in the LOCK system makes it physically 
impossible for a user process to access or 
tamper with the SIDEARM firmware or its 
data, giving the LOCK system a high degree of 
assurance. 

The host processor provides TCB- 
mediated resource management and comput¬ 
ing power for user applications. Since it 
performs no security access checks, the 
performance degradation imposed on the 
system by the security mechanisms should be 
minimal. 

The OS for LOCK will not be responsible 
for enforcing the security policy of the system, 
and therefore, it will not be part of the TCB 
and not have to be verified or evaluated when 
it is updated. 


Since UNIX is not part of the TCB, we will 
not have to modify it to provide MLS features. 
These capabilities are provided by the underly¬ 
ing TCB. Because of this, we should be able to 
maintain a great deal of compatibility with the 
SVID and, hence, with the existing base of 
applications. 

1.2. The Study Goals and Results 

During 1987, we performed a study of the 
UNIX kernel to determine if it could be 
(relatively easily) ported to the LOCK system, 
and if so, determine what the effect on the 
interfaces be. To enable us to determine if it 
would be worthwhile to port UNIX, we 
established the following research goals: 

• The number of modifications to the UNIX 
kernel should not be extensive. 

• The TCB could not be modified to “tailor” 
it to running UNIX. 

• UNIX had to be able to service many 
concurrent users running at different security 
levels without becoming part of the TCB. 

• The file system had to be able to manage 
data at different security levels requiring 
trusted servers and without introducing covert 
channels. 

• The resultant system must maintain a 
maximum compatibility with the SVID. 

The results of our study indicate that these 
goals can be met. The application-visible 
interface to the LOCK implementation of 
UNIX (LOCK/ix) is nearly identical to that of a 
standard implementation of UNIX System V. 
The security policy enforced by the underlying 
LOCK TCB should have little, if any, impact 
on the majority of existing UNIX applications. 

We feel one major result of the study is 
our approach for implementing an untrusted 
file system that will manage the multi-level 
data. Internally, our file system implementa¬ 
tion will be quite different than in a standard 
UNIX kernel. However, users and applications 
should not notice the differences. 
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1.3. Overview of the LOCK Architecture 

The LOCK system consists of two comput¬ 
ing units: the SIDEARM and the host proces¬ 
sor. The majority of the TCB functionality 
resides in the SIDEARM, whose firmware 
coordinates with a small (TCB) software kernel 
(the Supervisor) that runs on the host proces¬ 
sor. 

The resultant TCB provides low-level 
services for subject, object, and device 
management. The LOCK TCB is restricted, for 
reasons of verifiability, to minimum 
functionality. It is intended to support, not 
replace, traditional OS services, such as a 
hierarchical file system. 

The Supervisor (see Figure 1) functions as 
a low-level resource manager, and provides an 
application visible interface to the TCB’s 
capabilities. The Kernel Extensions are a set 
of verified, security-related utilities whose 
capabilities cannot be provided by the 
SIDEARM in a generic fashion. 

1.3.1. The SIDEARM 

The SIDEARM implements what is called 
the Reference Monitor (RM) concept (see Fig¬ 
ure 2). In general, an RM can be thought of as 
a guard between people and the information 
they would like to access. There are three 
important criteria for an RM: 

1. It must always be invoked. 

2. It must be verified to be correct (i.e., prop¬ 
erly enforce the security policy of the system). 

3. It must be tamperproof. 

The LOCK hardware-oriented approach (see 
Figure 3) provides a good match to the RM 
model [SAYD87], 

When the system is booted, the SIDEARM 
is booted and initialized before the host 
processor begins to run and continues to run 
until the system is shut down. All security- 
related data and most of the security 
functionality is implemented in the SIDEARM, 
thus making it possible to verify that it is 
correct. And finally, since the SIDEARM is 
physically separate (see Figure 4) and main¬ 
tains its own memory, there is no (physical) 
way for a user process to tamper with its 


firmware or data. It is unbypassable since it is 
the SIDEARM, and not the Host processor, 
that has exclusive control over the Memory 
Management Unit (MMU). 

1.3.2. The Host Processor 

As mentioned previously, a small software 
kernel (which is part of the TCB) runs on the 
host processor. This software kernel is 
responsible for preserving the security policy 
of the system by performing correct, low-level 
resource management. This software kernel, 
called the Supervisor, consists of code that 
runs in both privileged and user mode of the 
host processor. 

The portion of the Supervisor that runs in 
the privileged mode is only that code which is 
forced there by the hardware, such as the 
interrupt handlers. Other code, such as the 
subject scheduler, runs in the processor’s user 
mode. 

All code that runs in privileged mode will 
be placed in Read-Only Memory (ROM)) that 
is addressable only when the processor is run¬ 
ning in privileged mode, thereby making it 
tamperproof. Other software, such as the OS, 
will run in user mode on the host processor. 

2. Overview of the LOCK Security 
Model 

The LOCK TCB enforces a MLS policy. 
The policy is enforced by mediating access 
between subjects, the active entities of the 
system, and objects, the inactive entities of the 
system. 

To enforce this policy, the SIDEARM 
maintains a large database called the Global 
Object Table (GOT). Each time a subject or 
object is created, it is assigned a unique 
identifier (UID). A GOT entry is then created 
for the new entity where the UID is used as the 
primary key. A GOT entry will contain addi¬ 
tional information, such as the level and the 
creator. 

The LOCK TCB provides Discretionary 
Access Control (DAC) and Mandatory Access 
Control (MAC) mechanisms to enforce the 
system’s security policy. In order for a subject 
to be granted access to an object, the request 
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must be allowed by both the DAC and MAC 
mechanisms of the system. 

2.1. Discretionary Access Control Policy 

A DAC policy is discretionary because its 
administration is up to the discretion of the 
system users. The LOCK TCB provides Access 
Control Lists (ACLs) as the mechanisms for 
providing DAC. 

ACLs allow a user to specify, for each 
named object he owns, a list of named 
individuals and a list of groups of named 
individuals and their respective modes of 
access to the object. Additionally, for each 
named object a user owns, he may specify a 
list of named individuals and a list of groups 
of named individuals for which no access to 
the object is to be given. The currently 
supported modes of discretionary access are 
read (r), write (w), execute (x), and null (n). 

2.2. Mandatory Access Control Policy 

A MAC policy is mandatory because it is 
always enforced by the system. Unlike a DAC 
policy, the system users have no say in how 
the policy is administered. The LOCK MAC 
policy is enforced by Labeled Security Protec¬ 
tion and Type Enforcement mechanisms. 

2.2.7. Labeled Security Protection 

The LOCK TCB enforces Labeled Security 
Protection as required by the Orange Book. 
The policy is enforced over all system 
resources (e.g., subjects, objects, and I/O 
devices) that are directly or indirectly accessi¬ 
ble by subjects external to the TCB. 

The LOCK TCB maintains a SIDEARM- 
resident data structure that is a partially 
ordered set (POSet) of all security levels known 
to the system. When a subject and/or object is 
created, it is assigned one of the levels from 
the POSet. Access is then computed using the 
level of the subject requesting access and the 
level of the object being accessed in the follow¬ 
ing manner: 

• To read an object, the level of the subject 
must dominate the level of the object (the 
Simple Security Property). 


• To write an object, the level of the subject 
must be dominated by the level of the object 
(the ^-Property). 

As used in the rules above, the term 
“dominate” means less than or equal to. The 
POSet is consulted to determine if one level 
dominates another. 

2.2.2. Type Enforcement 

Type enforcement is a mechanism that is 
unique to the LOCK TCB. Not required by the 
Orange Book, it is this mechanism that will 
allow the LOCK TCB to exceed the Orange 
Book Class A1 requirements. Type enforce¬ 
ment is based on two attributes: 

• The domain of execution of a subject 

• The type of the object a subject is 
attempting to access. 

A domain is similar in concept to rings in 
ringed architecture machines. Unlike rings, 
though, there is no hierarchical relationship 
between domains. Moving from one domain 
to another does not necessarily imply an 
accumulation of increasing system privilege. 
Rather, each domain has a set of privileges 
different from other domains. 

To represent the domains and the 
privileges allowed in them, the TCB maintains 
a SIDEARM-resident data structure called the 
Domain Table. It contains the following infor¬ 
mation: 

• The UID of the domain 

• The human-readable name of the domain 

• A list of special privileges 

» A list of domains that can be transitioned 
to. 

The special permissions that are allowed in 
domains are the ability for a subject to take 
exception to the DAC and/or the Labeled 
Security Protection mechanisms of the system. 
Since it is the type enforcement mechanism 
that allows a subject to have these special 
privileges, a subject may never take exception 
to the type enforcement rules of the system. 

When a subject is said to have the ability 
to transition to another domain, this means 
that it can create another subject in the 
domain that is allowed to be transitioned to. 
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The domain of execution is an attribute of a 
subject that remains constant throughout its 
lifetime. In other words, a subject can only 
execute in one domain. 

All objects have a type associated with 
them. The concept of type is similar in nature 
to types in high level programming languages. 
The TCB restricts operations on objects of 
specific types based on the domain of execu¬ 
tion of the subject attempting the access. 

To represent types and the operations 
allowed on them, the TCB maintains a 
SIDEARM-resident data structure called the 
Type Table. It contains the following informa¬ 
tion: 

• The UID of the type 

• The human-readable type name 

• Allowable object sizes (minimum and 
maximum) 

• List of access vectors for the type in exist¬ 
ing domains 

• Default ACL. 

The list of access vectors defines all operations 
allowed on objects of a specific type for each 
domain defined in the Domain Table. 

When a subject requests access to (or 
attempts to create) an object, the TCB consults 
the Domain and Type Tables to determine if 
the access, based on the domain of execution 
and object type, is allowed. 

Both the Domain Table and Type Table 
are initialized at sysgen time by the System 
Security Officer (SSO) and are inaccessible to 
user processes. 

As mentioned earlier, type enforcement 
can be used to grant special privileges. For 
example, it may be necessary to implement an 
application that is allowed to downgrade files. 
The list of special privileges in the Domain 
Table is used to grant such privileges. The list 
of access vectors in the Type Table is used to 
restrict which object types can be read and 
written in the downgrade process. 

Type enforcement is also useful for 
integrity reasons. For example, the system 
may grant subjects running in a system 
administration domain read and write access 
to objects of type “password file.” Subjects 


running in the OS domain may be granted only 
read access to objects of type password file. 
With the Domain and Type Tables established 
in this fashion, the system will prevent 
unauthorized modification (integrity) of 
objects of the type password file. 

The type enforcement mechanism can be 
used to support a variety of integrity models 
such as the Clark-Wilson [CLARK87] model, 
and as described in [BOEB85], the Biba 
[BIBA75] model. 

2.3. Subjects 

The basic execution (active) entity in 
LOCK is the subject. A subject is a process 
that executes in a particular security context. 
The security context comprises the level of the 
subject, the domain of execution, and the user 
on whose behalf the subject is executing. In 
many ways, a subject is like a UNIX process: 
it shares the processor with other subjects 
through timeslicing, it has access to a “file 
system” that other subjects also have access to, 
it can open and operate on “files,” and it has 
limited capabilities for communicating with 
other subjects. 

There are some notable differences 
between subjects and UNIX processes. There 
are no hierarchical parent/child relationships; 
each subject is independent of the subject that 
created it. For UNIX processes with effective 
user IDs of superuser, the entire system is 
accessible; there is no corresponding notion of 
superuser in the LOCK UNIX world. Under 
UNIX, multiple processes can be writing to the 
process control terminal simultaneously; LOCK 
allows only one subject to perform terminal 
I/O at a time. 

All subjects have associated with them a 
Subject Translation Table (STT). The STT 
contains an entry for each object that the 
subject has opened (see Figure 5). In LOCK/ix 
objects are data files, text segments, data seg¬ 
ments, stack objects, and kernel level data 
structures. The STT is similar in nature to the 
UNIX per-user open file table. Each entry in 
the STT identifies an object and the current 
access that the subject has to it. The STT is 
resident in the host processor’s memory and 
provides the first level of address translation 
for the MMU. 
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V, but with the same mandatory access restric¬ 
tions imposed by the TCB. The set-user-ID 
execution mode affects only the UNIX-specific 
access permissions implied by UNIX user-IDs 
and does not cause a change in the LOCK user 
UID of the subject. 

There are two problems that arise with 
set-user-ID and set-group-ID applications. 
The problems exist because UNIX maintains 
both an effective-user-ID and real-user-ID for 
each process. These user-IDs are not always 
the same. In contrast, the LOCK TCB main¬ 
tains only a user-ID for each active subject. A 
LOCK subject user-ID and a process real-user- 
ID will be the same (the person who is actually 
running an application). 

The first problem arises from the fact that 
file system objects have ACLs associated with 
them. The LOCK TCB evaluates ACLs based 
on the real user’s identity. What this means is 
that there must be an ACL entry for the real 
user (who execOed the program) with the 
desired access rights for all files that the appli¬ 
cation will access. UNIX may allow a process 
to inherit the access rights of the owner of a 
set-user-ID application, but the TCB will not. 

The second problem arises from the fact 
that when an object is created, the TCB assigns 
as the owner attribute the name of the real 
user who created the file. Additionally, the 
ACL for the file is initialized with one entry for 
the owner. This will result in a conflict 
between who UNIX thinks is the owner and 
who the TCB thinks is the owner. 

When an object is initially created by the 
TCB, it is assigned a default ACL. This default 
ACL will contain only one entry that gives the 
owner read and write permission. This will 
have the effect (from a UNIX point of view), of 
giving the wrong person object access. The 
ACL entry will specify the name of the 
individual who ran the set-user-ID application, 
rather than the name of the individual who 
owns the application. 

We are currently investigating several 
alternative approaches to solving this problem. 
Since the UNIX user community appears to 
have a strong desire to continue to run set- 
user-ID applications, our current design will 
most likely be criticized as providing unaccept¬ 
able support for set-user-id applications. 


There are some within the computer 
security community who argue that a capabil¬ 
ity such as setuid should not be provided by 
A1 systems. This is a debate that is likely to 
continue for many years to come. Our feeling 
is that, in general, existing UNIX protection 
mechanisms and in particular the setuid capa¬ 
bility are really integrity mechanisms. If a 
method can be devised to support a fully func¬ 
tional setuid capability in a secure manner, we 
see no disadvantage to doing so. 

3.1. Memory Management 

UNIX kernel memory management func¬ 
tions provide user processes with an expand¬ 
able data area that can be used for dynamic 
heap allocation. The heap allocation algo¬ 
rithms are supplied by the run-time library 
and provide a generalized memory block allo¬ 
cation scheme to user programs. They call on 
the kernel to expand the user process’s data 
area as needed to increase the pool of memory 
that is available for allocation. 

Although not explicitly visible at the user 
program interface, UNIX memory management 
also normally enforces protection of user 
process address space from access by other 
processes. The kernel’s memory space is also 
protected from access by any user process. 
These attributes are dependent on the MMU 
hardware characteristics of the target machine. 
Since a LOCK/ix subject has no explicit control 
over the TCB’s MMU, such protection cannot 
be provided by LOCK/ix. 

The LOCK/ix kernel manages memory via 
calls to the TCB storage manager. The physi¬ 
cal allocation of memory is replaced by 
requests to create, delete, open, close, and 
expand the LOCK objects that compose the 
address space of user processes. Each user 
process within the subject is assigned text, data 
and stack objects by the kernel which are open 
to the subject as long as the process is execut¬ 
able. When a process terminates, these objects 
are closed and deleted by the kernel. 

Expansion of the data area of a user 
process is implemented by calling the TCB 
storage manager to expand the data object for 
the process. This TCB function automatically 
handles physical relocation of the object if 
needed and zeros the newly allocated space for 
LOCK/ix. 
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Expansion of the stack of a user process is 
implemented by a special LOCK/ix system call, 
which is used to request that the stack of the 
calling process be extended. This requires that 
the compiler generate a stack overflow check 
as part of every C function’s entry preamble 
code. Although relatively inefficient, this 
method of automatic stack growth is used on 
standard UNIX machines that have no 
hardware support for stack overflow detection 
in the MMU. Memory management is not 
affected by the TCB security mechanisms, since 
all functions are local to the LOCK/ix subject. 

4. The LOCK/ix File System Design 

During the course of the study, three 
options were identified for supporting a UNIX 
file system and accessing files at lower levels. 
It became clear that either a significant 
amount of trusted code would be required to 
support the UNIX file system as currently 
implemented, that a totally separate file system 
was required for each different level, or that 
the file system structure would have to change, 
but still appear to users and applications like 
the UNIX file system. 

The first option was discarded as being 
unacceptable from a design and implementa¬ 
tion point of view. Separate file systems 
would require minimum changes from the 
current UNIX implementation, but would 
create problems in usability and system 
maintainability since lower level files would be 
inaccessible. A redesign of the file system to 
make it appear as much like the UNIX file 
system as possible, yet fit into the MLS frame¬ 
work, became the most viable alternative. 

A separate file system at each level is 
supported. A separate inode table for each 
level will be stored in an object at the level of 
the file system. Directories map inodes to files 
as in existing UNIX implementations. The key 
difference in LOCK/ix is that directories with 
the same path name will exist at the multiple 
levels that are accessible to a subject. The 
directories are logically overlaid to produce a 
combined virtual directory. To a user process, 
there will always appear to be only one file 
system, as with UNIX. The level at which the 
user process is executing will determine which 
files are visible in its view of the file system. 


A directory can only contain files that are 
at the same level as the directory. However, if 
the same directory path exists at several levels, 
each containing files, applications are given the 
illusion that the directory contains files at 
multiple levels. Only the directory paths need 
to be duplicated, not the files. 

Figure 7 illustrates a simple two-level file 
system. Level 0 is lower in security level than 
Level 1. A LOCK/ix process running at Level 
0 would see the files cat and Is in the /bin 
directory. A Level 1 process would see those 
two files, and, in addition, the “magic” file. 
LOCK/ix performs the logical combination of 
the file systems at multiple levels. The files at 
Level 0 that the Level 1 process is aware of 
will never be writable. The view of the file 
system presented to a Level 1 process will con¬ 
tain the Level 1 file system overlaid on top of 
the Level 0 file system, as if each were a 
transparent figure. A Level 0 process will have 
no way of determining the existence of any¬ 
thing in Level 1 (or beyond), because LOCK 
will deny access to any Level 1 (or beyond) file 
system objects, including the inode table and 
root directory. 

The concept of virtual directories could 
also be applicable to a conventional, unsecure 
networked UNIX environment. If file systems 
resided on multiple machines, some with the 
same directory path names, virtual directories 
could be created. The issue of which network 
machine a file resided on would no longer be 
significant. 

4.1. Path Inheritance 

In order to support virtual directories, a 
method is needed whereby files can be created 
at the current level if the directory path exists 
at a lower level. It would be incompatible 
with UNIX to allow the creation of a directory 
that already exists. Therefore, LOCK/ix 
automatically creates (“inherits”) directory 
paths that exist at a lower level, but not the 
current level, when creating a new file in a 
directory. 

If a directory does not exist at an observ¬ 
able level, attempting to create a file in the 
directory will fail, as with UNIX. If the direc¬ 
tory does exist at the current level, no further 
action needs to be taken in terms of path crea¬ 
tion. Only when components of the path do 
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not exist at the current level does LOCK/ix 
need to automatically create them. The crea¬ 
tion of path components at the current level is 
handled in a completely transparent manner. 
Other than noting a slight delay, a user or 
process will not be aware that it is occurring. 

Path inheritance creates only the directory 
paths that are needed at a given level. A good 
analog is a virtual memory system. The work¬ 
ing set is at first very small, containing only 
the top-level path components. As files are 
created, as with pages not in memory, a fault 
occurs and the appropriate pages are brought 
in from disk, or in this case, path components 
are created. Eventually, a stable working set is 
established that handies most references, for 
either virtual memory or the LOCK/ix file 
system. The major difference is that the direc¬ 
tory paths created are permanent, real direc¬ 
tory entries that exist in the file system. There 
is no way to determine afterwards whether a 
directory path was inherited or explicitly 
created. 

If directories are created with names that 
(unknowingly and unintentionally) match 
those at a higher level, the higher level virtual 
directory view will contain all the files. The 
lower level view will only consist of those at 
the lower level. 

An open issue currently is how to resolve 
name collisions. If identically named files 
exist at multiple levels in a directory, the 
higher level processes will need a way to 
determine which version gets accessed. An 
extension to the namei routine, which 
performs name to inode mapping, is planned 
for the future. The main changes in logic to 
support file systems at different levels that are 
combined to appear as one composite file 
system have been in the name i module. 

4.2. File System Examples 

A few simple examples will help illustrate 
how the file system appears and operates. The 
examples are built on the file system shown in 
Figure 7. 

Figure 8 shows how the file system would 
appear if an application running at Level 1 
created a file named z in the directory 
/usr/user3. Before creating the z file, the 
LOCK/ix subject was required to create the full 


directory path at Level 1 so that the file would 
end up at the correct level in the file system. 
In this case, only the user3 path component 
was created, because the /usr component 
already existed. The inode numbers for each 
level can be, and typically will be, different for 
each level of the file system. The Level 1 
application creating the file z is unaware that 
the path is being inherited. There will still 
appear to be one /usr/user3 directory to 
both Level 0 and Level 1 applications, and 
they will appear to be the same, although the 
Level 1 application can potentially access addi¬ 
tional files. If a file named /usr/user3/z 
already existed at Level 0, the Level 1 applica¬ 
tion would not be able to create the file, since 
one would already exist as a read only file. A 
Level 0 application can create a file named 
/usr/user3/z, since the Level 1 version 
would not be visible. The Level 1 application 
would still access the Level 1 copy. If the 
Level 1 application deleted its copy of the z 
file, the Level 0 file z would remain in the file 
system. 

Figure 9 illustrates the file system after 
making the directory /usr/user2/da at Level 
0, then creating the file z in that directory. 
There was no directory appearing to the Level 
0 processes by the Level 0 name before the 
directory was created, although one existed at 
a higher level. There will still appear to be 
one /usr/user2/da directory to the Level 1 
process, but there is now a read-only file 
named z in the directory. 

Figure 10 shows the results of the deletion 
of the directory /usr/user3 by a Level 0 
process. To the Level 0 process, the directory 
appeared to be empty, thus it was permissible 
to unlink the directory. Without path 
inheritance, trusted code would be required to 
make sure that the file z created in the previ¬ 
ous example was properly connected in the 
directory structure when the Level 0 path was 
deleted. With path inheritance, the file was 
created on a valid directory path to begin with, 
and the lower level process did not need to 
perform any special processing to account for 
files created at higher levels. 
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4.3. Integrity Considerations 

The LOCK/ix kernel runs in the same 
address space as user processes. LOCK does 
not allow a single subject to execute in multi¬ 
ple domains. A process within a given 
LOCK/ix subject could gain access to any 
kernel file structures at its level and modify 
them. For this reason the file system update 
operations are removed from the LOCK/ix 
kernel and implemented as separate file system 
server subjects per level. Independent of a file 
system server, LOCK will provide protection 
for files from an aberrant program if the 
program does not have update (or write) access 
to the file. 

The file system inode table is broken out 
into two parts: non critical components, such 
as time modified, and critical components, 
such as object UIDs. The non critical 
components consist of fields that can be 
updated by the LOCK/ix kernel and that would 
not cause any problems if they were incorrect. 
The critical component will be in a different 
object type, which can be accessed by the 
LOCK/ix kernel, but not modified by it. The 
file system server subject will run in a domain 
that is different than that of the LOCK/ix 
kernel and user processes, and will have 
update access to the critical inode table. 

The file system server will only perform 
file system update operations; it will not run 
processes. No malicious programs that could 
cause unexpected and undesirable conse¬ 
quences will run. This particular instance 
shows how Type Enforcement can be used to 
support an integrity policy that will achieve 
the desired end result. 

5. Conclusion 

The results of our study are encouraging. 
We were surprised to find how much of the 
UNIX kernel code can be retained unmodified. 
However, our conceptual design has not been 
put to the test; it is only a paper design. We 
plan to begin implementation of LOCK/ix in 
April 1988, with the first version of the system 
running by April 1989. 

The LOCK/ix system design is really in its 
infancy. There are some issues that we did 
not address in the study in much detail, such 


as performance. Our future plans for enhance¬ 
ments include refining the file system design, 
solving the setuid problem, and extending the 
standard interface to incorporate security- 
relevant functionality provided by the underly¬ 
ing TCB. The latter will provide the 
capabilities necessary to develop Multi-Level 
applications. 
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Reference Monitor Concept 
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1. Always invoked 

2. Verfied correct 

3. Tamperproof 

Figure 2 


Reference Monitor in LOCK 



Hardware Advantages 

1. Always invoked - No way to bypass 

2. Verified correct - Simpler; machine indpendent 

3. Tamperproof - No way to attack security 

processor component 

Figure 3 


Reference Monitor in LOCK 
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Figure 4 
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Typical LOCK/ix Subject STT 
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Figure 5 


LOCK/ix Address Space Organization 
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Initial Two Level File System Example 
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File System After File /usr/user3/z 
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File System After Direrctory /usr/user2/da and 
File /usf/user2/da/z Createo by Level 0 Process 
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Deleted by Level 0 Process 
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An Update on UNIX Standards Activities 

Shane P. McCarron, NAPS Inc. 

April 17, 1988 


Overview 

This is the second in a series of reports on 
the UNIX standards community. In this arti¬ 
cle I will give you a summary of what 
happened at the March meeting of the POSIX 
committees. I will also explain what happened 
during the IEEE PI003.1 balloting, and why 
there is going to be another round of review 
and comment during May. In addition I will 
discuss what is going on with the National 
Bureau of Standards (NBS) Federal Informa¬ 
tion Processing Standards (FIPS), and how this 
will affect both implementors and program¬ 
mers in the short and long term. Those of you 
who saw the first article in this series will 
remember that the title was “An update on 
UNIX and C Standards Activities.” That 
changed this time because the ANSI X3J11 
meeting isn’t until mid-April, and there hasn’t 
been too much going on between meetings 
(other than a public review). Next quarter I 
will return to the C arena as well. 

P1003.1 Final Ballot? 

Those of you who saw the first issue of 
this column may remember that I reported on 
the status of the PI003.1 balloting. At that 
time I stated that the standards would be fully 
ratified in March... Well, I was wrong. 
Although the IEEE review board gave the 
standard conditional approval, it did not pass 
in its first round of balloting, nor did it pass in 
the first recirculation for review and comment. 
Needless to say, I was a little surprised, but 
there were many factors that figured into the 
problem. 

In the interest of clearing the air, below 
you will find a chronological account of the 
balloting procedure. I have also outlined the 
IEEE requirements for balloting, and how 
PI003.1 worked within these constraints. Even 
though you may finish reading the summary 
with an uneasy feeling about the process, 
please keep in mind that until recently there 
have been no large IEEE standards. The 


procedures were designed for brief documents 
describing the characteristics of three-phase 
power, not for 400 page documents specifying 
all the characteristics of an operating system. 

On November 15th the Standard went out 
to the balloting group. The balloting group 
consists of IEEE or IEEE Computer Society 
members who have indicated an interest in 
voting on this standard. When balloters vote 
no, they must return a document which states 
their specific objections, and what can be done 
to resolve them. Although specific wording is 
not required, it is encouraged. 

On December 15th (actually, a little after) 
balloting on the standard closed. The official 
IEEE length of a balloting period is 30 days, or 
until 75% of the balloting group members have 
returned a ballot, whichever is later. When 
75% of the ballots had been returned, the 
standard did not have the necessary percentage 
of yes votes (75%) for approval. At this point 
the standard and the ballots were turned over 
to the Technical Reviewers for resolution. 

On January 15th (or so) the committee 
chair started to assemble the ballot resolution 
documents for recirculation to the balloting 
group. The resulting document was a 
summary of all the changes made to the 
standard to resolve balloting objections or 
comments. In all there were 140 pages of 
changes, and (unfortunately) they were poorly 
organized and formatted. In my own defense 
(as a Technical Reviewer) I can only say that 
the process was rushed, and I procrastinated a 
little. Also, communication among the Techn¬ 
ical Reviewers was lacking, and the guidelines 
for reviewing and acting on ballots were 
unclear. This is all kind of tragic, but it was 
certainly an educational experience. 

On February 5th the resolution document 
was resubmitted to the balloting group for a 10 
day review period that was to start on the 
15th. Unfortunately the mail was held up 
until the 15th (or in some cases the 17th) and 
many balloting group members did not receive 
the recirculation document until the 20th or 
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later, for return to the IEEE Standards office by 
the 25th. Worse yet, the IEEE balloting 
procedures state that if the technical reviewers 
have resolved all objections in a ballot, that 
ballot automatically becomes a yes. The 
balloter must specifically indicate that his/her 
ballot is still negative. This was not made 
very clear to the balloting group, and many 
people did not resubmit a ballot. 

Fortunately many people did complain 
about the short review period and the 
problems with the recirculation document. 
Eventually it was discovered that the 10 day 
period that IEEE stipulates for reviews is a 
minimum, not a maximum. There was a lot 
of finger pointing and complaining on all sides, 
and in the end it was decided that even though 
the standard had the necessary 75% approval, 
there would be another recirculation. 

During the week of March 7th, the IEEE 
Standards Board met. In spite of all the 
problems with the standard, and all of the 
letters of protest that they received (including 
one from each of the Institutional 
Representatives, if I am not mistaken), the 
board conditionally approved the standard. 
[You’re not mistaken: the Institutional 
Representatives of USENIX, /usr/group and 
X/OPEN all sent letters of protest to the 
Standards Board; I also spoke to the Standards 
Activities Group directly about the time limit 
problem, -jsq] This conditional approval is 
an unprecedented event (as far as I can tell) 
and means that the standard can become fully 
ratified before the next meeting of the 
standards board once the second recirculation 
has been completed and it has sufficient 
positive ballots. There was a lot of screaming 
about this as well. 

During the week of March 14th the POSIX 
committees met in Washington D.C. 
Throughout the meetings the co-chair of 
PI003.1 met with each of the Technical 
Reviewers and very carefully went through 
their sections of the document, making sure 
that all objections and comments had been 
considered, processed, and responded to. This 
was an incredibly time consuming and painful 
process, but I believe that it resulted in a 
much better standard. During the last few 
weeks the Technical Reviewers have continued 
to work closely with the co-chair to get the 
second recirculation document put together. It 


should be completed and sent to the Technical 
Reviewers (as a safety check) in mid-April. 
Once the Reviewers think that it is clean 
enough, it will be sent out to the balloting 
group for a second review and comment 
period. 

The second recirculation will be handled 
quite a bit differently than the first. All 
members of the balloting group will receive a 
new copy of the standard (Draft 12.3) that will 
have change bars only in those places where 
changes have been made as a result of ballot¬ 
ing objections or comments. In addition, each 
balloter will receive a document detailing all of 
the unresolved objections, their nature, and 
why they were not resolved. The balloting 
group will have a longer period to respond to 
this document (> 10 days), but they shouldn’t 
need much more time, as most of the changes 
in the document were already detailed in the 
first recirculation document (although they 
were not made in context - that is to say they 
were not in a new draft, but rather listed as 
changes to draft 12). At the end of this 
recirculation and balloting period it is believed 
by most members of the committee that the 
standard will be complete. 

The time frame for all of this is late 
April/early May. 

I apologize for the length of this summary, 
but I think it is important that everyone know 
just what happened. Of course, this is just one 
man’s perspective, but I think that it is a fair 
one. I believe that the completed standard 
will be one which was carefully considered and 
designed, even if it won’t make everyone 
happy. 

NBS POSIX FIPS 

As I reported last quarter, the National 
Bureau of Standards has specified a Federal 
Information Processing Standard for POSIX. 
This FIPS has now been called an Interim 
FIPS, and is based on Draft 12 of the POSIX 
standard (the draft that went to the balloting 
group). This is unfortunate, since the post 
balloting draft is significantly different in a 
number of areas. Also, the NBS has made 
some changes in their requirements for the 
FIPS since I last reported them. As of this 
writing the POSIX Interim FIPS for the System 
Services Interface is not official. It is going 
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through the government signature maze within 
the Department of Commerce, and is expected 
to emerge sometime in April. 

This Interim FIPS will remain the 
standard until the PI 003.1 standard is 
completed. Sometime after that the NBS will 
put together a final FIPS based on . 1. 
Unfortunately, this may not be for several 
months after . 1 is completed. In the meantime 
government agencies will be generating 
Requests for Procurement (RFPs) which 
stipulate the Interim FIPS. 

What this means for systems implemen¬ 
tors is not entirely clear. The government will 
be requiring (at least for a little while) a 
standard that is in many ways incompatible 
with the final PI003.1 document. Obviously 
implementors have two options: 1) put 
together POSIX conforming systems and wait 
until the final FIPS is complete before selling 
any systems, or 2) put together a FIPS 
conforming system and be able to start selling 
immediately. Fortunately implementors have 
an out here - many of them have release 
cycles lasting anywhere from 6 to 18 months. 
By the time there is a POSIX standard and 
they get their implementation ready to be 
released, the FIPS will have changed to reflect 
the final standard... maybe. 

What it means to application developers is 
a little more obvious. Software that is in 
development today is probably too far along to 
consider making it POSIX conformant - or 
worse yet, ANSI C conformant. Software that 
is not yet in programming is going to take 
quite a while to get to market, so it can be 
made POSIX conformant without having to 
worry about the Interim FIPS. 

In addition to this first FIPS, the NBS has 
stated that it is going to be releasing several 
more Interim FIPS based on some of the other 
POSIX work in progress, as well as the work of 
other groups (like AT&T and the SVID). Dur¬ 
ing the POSIX meetings in Washington, Roger 
Martin from the NBS (and also chair of 
P1003.3 - Testing and Verification) made 
presentations to the various committees, 
explaining what the NBS intends to do in the 
next year with Interim FIPS. 

In May or June an Interim FIPS for the 
Shell and Tools interface (POSIX PI003.2) will 
be proposed. It will be based on Draft 6 of 


the .2 document, and will contain (at least) the 
command set from that document. It may 
also contain text from that document, or in 
cases where the text is felt to be immature, will 
contain text from the SVID or some other 
source. This Interim FIPS will be based on 
Draft 6 until the final standard is completed 
sometime in later 1989. 

In addition, the NBS will be releasing 
several other FIPS. These will be in the areas 
of Terminal Interface Extensions, System 
Administration, and Advanced Utilities. 
These are all terms from the SVID, and relate 
to just the things that you think they do. The 
Advanced Utilities FIPS may be rolled into the 
P1003.2 FIPS, since .2 encompasses most of 
those items that they wanted in there. The 
others will be based directly on the SVID (as 
far as I know). These are all to be in place by 
the end of 1988. This is an ambitious 
schedule, even for NBS. However if they meet 
it, it will mean that by the end of this year the 
government will have standards on most 
aspects of the UNIX operation system, and 
system implementors and application develop¬ 
ers will have to conform. 

IEEE P1003 Activities 

As I mentioned above, the POSIX 
committees met in Washington D.C. in March. 
For the first time, all 7 of the committees met. 
As you can imagine, it was pretty difficult to 
catch all of what went on, but here are the 
highlights. 

P1003.0 - POSIX Guide Project 

This group met for the first time in Wash¬ 
ington. Although they didn’t get a lot of tangi¬ 
ble work done, they did establish what their 
goals were, as well as starting to put together a 
timetable for production of their guide docu¬ 
ment. I don’t have the details of this yet, but I 
will next quarter. 

P1003.1 - System Services Interface 

This group met to decide what we are 
going to be working on in the future. We have 
a few items that must be handled by the .1 
group, and some that could be. Currently 
there are three projects being worked on by 
members of the committee: 
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Language Independent Description The ISO 
POSIX Working Group has requested that a 
language independent version of the . 1 
standard be produced as soon as possible after 
completion of the standard. Language bind¬ 
ings (like the current descriptions that are in 
the standard and the work being done by the 
.5 group) would be placed in supplements to 
the main standard, or in chapters within the 
standard itself. 

Improved Archive Format Although the ISO 
community agrees that cpio and us tar are 
fine for the first cut of the standard, they have 
requested that . 1 work on a more robust 
archive format that doesn’t have the technical 
drawbacks of either, as well as one that takes 
into account the security features needed for 
trusted systems. 

Terminal Interface Extensions Yes - we mean 
curses/Terminfo. Well, not really, but some¬ 
thing very much like that. It will have to be 
something that resembles current practice (I 
imagine), but it could be improved in little 
ways. There was a lot of sentiment in the 
group for throwing out all of the Terminfo 
stuff and starting from scratch, but I don’t 
think it will happen. We will probably get 
some proposals that are wildly different from 
existing practice, but it is outside the group’s 
charter to totally supplant existing practice. 

P1003.2 - Shell and Tools Interface 

The .2 Group got a lot of work done in 
Washington. They went in with a 400 page 
draft 5, and by end of May a 450+ page draft 
6 should be completed. This draft 6 will be 
used as the basis of the interim FIPS that the 
NBS will be using for their Interim FIPS on 
POSIX (see above). 

The most significant developments in .2 
were: 

Source Code Control The committee felt that 
source code control was outside the scope of 
the standard, and it was removed (it had been 
added at the last meeting). A number of peo¬ 
ple still feel that some form of source code 
control should be in there, so the committee 
left a place in the document where it could be 
put back in later. The real danger here is that 
the res people and the sees people will get 
into a religious war similar to the one that 


erupted between the tar and cpio factions in 
the .1 group. 

Basic Shell Changes There were many 
features of the Bourne shell that had been 
included in .2 for historic reasons. At this 
meeting the shell subcommittee agreed to 
remove some of those anachronisms. This will 
make way for (possibly) more enhancements to 
the basic shell mechanism in the future (e.g., 
substring manipulation). 

Software Installation Two drafts past there 
was a very complex system in the standard 
that allowed software installation in a portable 
way. This was removed in the December 
meeting, and replaced at the March meeting by 
a very simple interface that should be accept¬ 
able to everyone. Although the details are not 
all clear, it looks like this will consist of an 
implementation defined command that will 
read the first file off of a POSIX conforming 
archive (tape) and execute it. Anyway, some¬ 
thing about that difficult. 

Electronic Mail Interface mailx was added in 
Draft 5 as a proposed way to portably transmit 
mail. Some committee members felt that the 
way in which it was described was too 
restrictive, while others felt that it was too 
liberal. In a compromise move, another 
interface was defined that allows very simple 
mail transmission in a portable manner. It 
also has a name that doesn’t conflict with 
existing utilities. 

P1003.3 - Testing and Verification 

At the March meeting the chair 
announced that they were on target for 
completing the assertion lists for P1003.1, and 
that the .3 standard for .1 would be ready to 
ballot just as soon as the .1 standard was 
ratified. He also stated pretty clearly that 
P1003.3 didn’t want to work as hard when 
generating verification standards for the other 
POSIX committees. He asked that in the 
future the standards be written in a way that 
makes it easier to develop assertion lists. The 
.3 committee will be working closely with the 
.2 effort (which is a little too far along to fix 
now), but the other committees will be chang¬ 
ing their documents to reflect what assertion 
tests can be made about each function or 
command being defined. This should make it 
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easier to produce verification documents for 
those standards. 

P1003.4 - Real Time 

This committee made a lot of progress in 
the March meeting. However, they have a 
long road ahead of them, and I don’t know 
that anything earth shattering happened - cer¬ 
tainly nothing that I heard about. However, 
they have stated a target of 1990 for comple¬ 
tion, and at this point it is a little early to 
draw any sort of conclusions. 

P1003.5 - Ada Binding for the System 
Services Interface 

The Ada™ group is still a very young 
committee, but they are moving right along. 
At the very least they are generating a lot of 
paper, but it has some excellent stuff on it. 
Although they haven’t been a working group 
long, I expect to see a draft from them in the 
next six months, and a standard being balloted 
in a year. Although this may seem like a long 
time, it is really short work for a standards 


committee. Unfortunately, their work is very 
dependent on . 1 getting a language 
independent description of the System Services 
Interface put together as quickly as possible. 
They have already looked into ways of describ¬ 
ing POSIX independent of any language, and 
they will be helping . 1 get this firmed up. 

P1003.6 - Security 

This was the first meeting of .6 as a real 
IEEE committee. They defined their scope and 
objectives, set a tentative production schedule, 
and defined the format of their document. As 
a /usr/group technical committee they pro¬ 
duced a number of white papers, and I expect 
to see drafts coming out of the group based on 
those papers shortly. The only snag here is 
that the transition from a /usr/group technical 
committee to an IEEE working group wasn’t as 
smooth as others have been. To help alleviate 
some of the tension this caused, the next .6 
meeting will be held in conjunction with 
USENIX in San Francisco in June, instead of 
with the POSIX committees in July. After that 
they will follow the regular POSIX meeting 
schedule. 


Additional Corrigenda to the 1987 Graphics Proceedings 

Steve Strassmann’s name was universally spelled wrong; it should have two -ns, as here. 

Equations 20a, 20b, and 20c (p. 59) in Jane Wilhelms’ paper were munched. Correct equations 
appear in the revised version of her article in Computing Systems, vol. I, no. 1. 

My apologies to both Steve and Jane. 

Peter H. Salus 
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Summary of the Board of Directors’ Meeting 
Dallas, TX, February 7, 8 & 11,1988 


Attendance 

Present at the meeting were: Stephen C. 
Johnson, Rob Kolstad, Marshall Kirk 
McKusick, Alan G. Nemeth (President), John 
S. Quarterman, Deborah K. Scherrer, Waldo 
M. Wedel, David A. Yost - Directors; Sharon 
Murrel, Michael D. O’Dell, Charles H. Sauer - 
nominees; Rick Adams, UUNET; Peter Collin- 
son, EUUG secretary; Judith F. DesHamais, 
Conference Coordinator; John L. Donnelly, 
Tutorial Coordinator and Exhibit Manager; 
Donnalyn Frey, Frey Communications; Greg 
Hidley, San Diego program chair; Lou Katz, 
FaceSaver; Sam Leffler, San Francisco program 
chair; Betty J. Madden, office manager; Peter 
H. Salus, Executive Director. 

FaceSaver 

As there have been many requests 
concerning the FaceSaver data, it was agreed 
that Katz and Adams would discuss on-line 
availability. If on-line availability is feasible, 
it will be announced in ;login:. Adams is to 
report to the Board in San Francisco in June. 

Computing Systems 

O’Dell was congratulated on the first issue 
of Computing Systems and there was discus¬ 
sion of the possibility of other publishing 
projects involving the University of California 
Press. Salus is to negotiate the possibility of 
publishing a series of workshop proceedings 
papers. 

Workshops 

In 1987 the Association sponsored an 
unprecedented four workshops (Systems 
Administration, Graphics, POSIX, and C++). 
In 1988 this will grow further to four 
workshops (Real-Time, Security, Supercomput¬ 
ing, and Systems Administration II) and a 
C++ mini-conference. There was some 
discussion of 1989, with transaction processing 
a likely workshop. 


Tutorials 

There was a lengthy discussion of the 
current tutorial offerings and of the 
possibilities for the future. There will be 20 or 
21 tutorials offered in San Francisco. Among 
others, PostScript, ICON, Andrew, X.400 mail, 
and JCPIC were mentioned as future tutorials. 

Elections 

There was a discussion of election 
procedures. There was also a discussion of 
possible bylaw changes involving the nature of 
the Board, the form of the elections, and the 
concept of requiring prior Board service of 
candidates for Officer’s posts. 

It was decided that the President should 
strike a committee to look into procedures and 
to report in San Francisco. Nemeth struck 
such a committee comprised of Katz, Lepreau, 
McKusick, Tilson, and Yost. 

UUNET 

Adams delivered a report on the UUNET 
service. There were currently 241 subscribers. 
There are some problems with the Sequent OS. 
There was a discussion of Tymnet, Sprint, 
AT&T 800 numbers, etc. 

There was also a prolonged discussion of 
the future of UUNET, how it should be organ¬ 
ized, and just what its relationship to USENIX 
was and what it should be. There was a 
discussion of East Coast and West Coast sites 
and of Adams’ present and future status. 
Nemeth struck an ad hoc committee of him¬ 
self, Wedel, Johnson, and Adams to 
recommend actions to the Board. Collinson 
warned of the implications to mcvax of the 
relocation of the Sequent. There was a sugges¬ 
tion made by Quarterman that UUNET find a 
way of billing cisatlantic users for transatlantic 
mail. Currently, Europe pays for both ends of 
the transmission. 

On Thursday, when the ad hoc committee 
had been unable to come to satisfactory 
conclusions in the short time-frame, Nemeth 
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struck a committee of Adams, Johnson, 
Scherrer, and Wedel (with Salus as notetaker) 
to report in San Francisco. 

Public Relations 

Frey reported on her activities and on her 
placement of articles and press releases. There 
was a discussion of the need for public rela¬ 
tions where the Association was concerned. 
There was a further discussion of the role of 
/etc/motd. 

Treasurer’s Report 

There was a long discussion of the 
Association’s finances, especially as the 
acquisition of hardware and the funding of 


UUNET had resulted in the Association using 
some of its cash reserves in 1986-87. [The 1987 
Financial Statements appear in this issue of 
;login:, pp. 32-34.] 

P1003 Report 

Quarterman reported on PI003 activities. 
[McCarron’s report appears in this issue of 
;logirt:, pp. 25-29.] 

Membership Survey 

Following a discussion of the 1986 
membership survey and of the survey Yost 
had conducted at the C++ workshop, it was 
decided that Salus would revise the forms used 
and make recommendations in San Francisco 
concerning a membership survey in Fall 1988. 


FYI 


From The Observer, 14 April 1988, 

Open Look is yet another Macintosh-like user interface soon to be launched by AT&T, Sun 
Microsystems and Xerox. The idea is to make UNIX, the cryptic and unfriendly operating system 
owned by AT&T, usable by ordinary mortals. 

-Jack Schofield 
Computer Editor 


I assume all USENIX members to be immortal. -PHS 
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Financial Statements for the USENIX 
Association for Fiscal Year 1987 
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USENIX ASSOCIATION 

CONFERENCE AND WORKSHOP INCOME - EXHIBIT A 
FOR THE YEAR ENDED NOVEMBER 30, 1987 
_ (Unaudited) _ 


....Conferences.... .Workshops 



Adminl- 

Washington 



Phila- 

Santa Fe/ 




stratlon 

D.C. 

Phoenix 

Monterey 

delphla 

Dallas 

Other 

Total 

REVENUE: 









Registration fees 


$356,501 

$561,227 

$ 1,343 

$9,647 

$46,434 

$22,163 

$997,315 

EXPENSES; 









Refunds 

$ 220 

5,663 

5,759 





11,642 

Pre-announcement mailing 


4,120 

979 



7,093 


12,192 

Pre-registration 

30 

8,380 

24,184 



10,413 


43,007 

Registration packet 


13,647 

3,550 





17,197 

Tutorial expense 

234 

43,739 

63,218 





107,191 

Rent 

4,600 


4,444 





9,244 

Advertising 


21,276 

11,034 



1,603 


33,913 

Credit card charges 

485 

1,551 

2,837 


43 



4,916 

Temporary office help 

27,688 


392 





28,080 

Telephone 

4,081 

27 






4,108 

Refreshments 


10,425 






10,425 

Consulting and planning fees 

89,534 



2,400 




91,934 

Travel and meetings 

1,606 

19,023 

41,754 

4,783 

9,493 

10,682 

198 

87,539 

Security 


7,785 






7,785 

Catering and restaurant charges 


8,152 

9,493 





17,645 

Shipping and postage 

4,268 

2,806 

6,664 



953 


14,691 

Conference signs 


625 

640 





1,265 

USENIX and /usr/ group booth 


78 






78 

Receptions 


1,378 






1,378 

Office supplies 

6,190 

50 

7,987 





14,227 

Equipment rental and maintenance 

78 

515 

201 





794 

Program committee expenses 


2,549 

3,425 



75 


6,049 

Decorations 


697 






697 

Computer 

5,149 







5,149 

FACESAVER project 



7,819 





7,819 

Printing 



9,225 



329 


9,554 

Poelx Workshop 







9,956 

9,956 

Graphic Workshop 







9,333 

9,333 

Site inspection 






834 


834 

Technical conference 






4,090 


4,090 

Rawhide Reception 



31,062 





31,062 

Tech session expenses 



19,662 





19,662 

Miscellaneous 

1,152 


539 

9,644 




11,335 

Total expenses 

145,515 

152,486 

254,868 

16,827 

9,536 

36,072 

19*487 

634,791 

CONFERENCE AND WORKSHOP INCOME (LOSS) 

$(145,515) 

$204,015 

$306,359 

$(15,484) 

$ 111 

$10,362 

$ 2,676 

$362,524 


Soc accompanying notes to financial statements. 
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Future Events 


USENIX 1988 Summer Conference and 
Exhibition San Francisco, June 20-24,1988 

UNIX Security Workshop 
Portland, OR, Aug. 29-30, 1988 

The Program Chair is Matt Bishop of 
Dartmouth College. See page 6. 

AUUG Winter Conference 
Melbourne, Sept. 13-15,1988 

For information write Tim Roper: 
uunet!munnari!labtam.oz!timr 

UNIX and Supercomputers Workshop 
Pittsburgh, PA, Sept. 26-27, 1988 

Program Chairs are Melinda Shore of the 
Pittsburgh Supercomputer Center and Lori 
Grob of New York University. See page 7. 

EUUG Autumn Conference 
Portugal, Oct. 3-7,1988 

See page 10. 


C++ Miniconference 
Denver, CO, Oct. 17-21,1988 

The Program Chair is Andy Koenig of 
AT&T. See page 8. 

Large Installation 
System Administration II 
Monterey, CA, Nov. 17-18,1988 

The Program Chair is Alix Vasilatos of 
MIT’s Project Athena. See page 9. 

EUUG Spring Conference 
Brussels, Apr. 10-14,1989 

Long-term USENIX Conference Schedule 

Jan 31-Feb 3 ’89 Town & Country Inn, San Diego 

Jun 12-16 ’89 Hyatt Regency, Baltimore 

Jan 22-26 ’90 Washington, DC, Omni Shoreham 

Jun 11-15 ’90 Marriott Hotel, Anaheim 

Jan 22-25 ’91 Dallas 

Jun 10-14 ’91 Opryland, Nashville 


Publications Available 


The following publications are available 
from the Association Office. Prices and 
overseas postage charges are per copy. 
California residents please add applicable sales 
tax. Payment must be enclosed with the order 
and must be in US dollars payable on a US 
bank. 


The EUUG Newsletter, which is published 
four times a year, is available for $4 per copy 
or $16 for a full-year subscription. 

The July 1983 edition of the EUUG 
Micros Catalog is available for $8 per copy. 


Conference and Workshop Proceedings 


Meeting 

Location 

Date 

Price 

Overseas Mail 
Air Surface 

USENIX 

Dallas 

Winter ’88 

$20 

$25 

$5 

C++ Workshop 

Santa Fe 

November ’87 

20 

25 

5 

Graphics Workshop IV 

Cambridge 

October ’87 

10 

15 

5 

USENIX 

Phoenix 

Summer ’87 

10 

25 

5 

USENIX 

Wash. DC 

Winter ’87 

10 

25 

5 

Graphics Workshop III 

Monterey 

December ’86 

10 

15 

5 

USENIX 

Atlanta 

Summer ’86 

10 

25 

5 

Graphics Workshop I 

Monterey 

December ’84 

3 

7 

5 
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4.3BSD Manuals 


The USENIX Association now offers all 
members of the Association the opportunity to 
purchase 4.3BSD manuals.* 

The 4.3BSD manual sets are significantly 
different from the 4.2BSD edition. Changes 
include many additional documents, better 
quality of reproductions, as well as a new and 
extensive index. All manuals are printed in a 
photo-reduced 6"x9" format with individually 
colored and labeled plastic “GBC” bindings. 
All documents and manual pages have been 
freshly typeset and all manuals have “bleed 
tabs” and page headers and numbers to aid in 
the location of individual documents and 
manual sections. 

A new Master Index has been created. It 
contains cross-references to all documents and 
manual pages contained within the other six 
volumes. The index was prepared with the aid 
of an “intelligent” automated indexing 
program from Thinking Machines Corp. along 
with considerable human intervention from 


Mark Seiden. Key words, phrases and 
concepts are referenced by abbreviated docu¬ 
ment name and page number. 

While two of the manual sets contain 
three separate volumes, you may only order 
complete sets. 

The costs shown below do not include 
applicable taxes or handling and shipping from 
the publisher in New Jersey, which will 
depend on the quantity ordered and the 
distance shipped. Those charges will be billed 
by the publisher (Howard Press). 

Manuals are available now. To order, 
return a completed “4.3BSD Manual 
Reproduction Authorization and Order Form” 
to the USENIX office along with a check or 
purchase order for the cost of the manuals. 
You must be a USENIX Association member. 
Checks and purchase orders should be made 
out to “Howard Press.” The manuals will be 
shipped to you directly by the publisher. 


Manual Cost* 

User’s Manual Set (3 volumes) $25.00/set 

User’s Reference Manual 
User’s Supplementary Documents 
Master Index 

Programmer’s Manual Set (3 volumes) $25.00/set 

Programmer’s Reference Manual 
Programmer’s Supplementary Documents, Volume 1 
Programmer’s Supplementary Documents, Volume 2 

System Manager’s Manual (1 volume) $10.00 

* Not including postage and handling or applicable taxes. 


4.2BSD Manuals are No Longer Available 


f Tom Ferrin of the University of California at San Francisco, a former member of the Board of Directors of the USENIX 
Association, has overseen the production of the 4.2 and 4.3BSD manuals. 
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4.3BSD Manual Reproduction Authorization and Order Form 

This page may be duplicated for use as an order form 

USENIX Member No.:_ 

Purchase Order No.:_ 

Date:_ 

As a USENIX Association Member in good standing, and pursuant to the copyright notice as 
found on the rear of the cover page of the UNIX®/32V Programmer’s Manual stating that 

“Holders of a UNIX®/32V software license are permitted to copy this document, or any portion of it, as 
necessary for licensed use of the software, provided this copyright notice and statement of permission 
are included,” 

I hereby appoint the USENIX Association as my agent, to act on my behalf to duplicate and provide 
me with such copies of the Berkeley 4.3BSD Manuals as I may request. 

Signed:_ 

Institution (if Institutional Member):_ 

Ship to: Billing address, if different: 

Name:_ Name:_ 


Phone:_Phone:_.__. 

The prices below do not include shipping and handling charges or state or local taxes. All pay¬ 
ments must be in US dollars drawn on a US bank. 

4.3BSD User’s Manual Set (3 vols.) _ at $25.00 each = $___ 

4.3BSD Programmer’s Manual Set (3 vols.) _ at $25.00 each = $____ 

4.3BSD System Manager’s Manual (1 vol.) _ at $10.00 each = $_ 

Total __ $__ 

[ ] Purchase order enclosed; invoice required. 

(Purchase orders must be enclosed with this order form.) 

[ ] Check enclosed for the manuals: $ _ _ 

(Howard Press will send an invoice for the shipping and handling charges and applicable taxes.) 

Make your check or purchase order out to “Howard Press” and mail it with this order form to: 

Howard Press 
c/o USENIX Association 
P.O. Box 2299 
Berkeley, CA 94710 


for office use: m.v.: 


check no.: 


amt. rec’d: 
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Local User Groups 

The USENIX Association will support local user groups by doing an initial mailing to assist the 
formation of a new group and publishing information on local groups in ;login ;. At least one member 
of the group must be a current member of the Association. 


CA - Fresno: the Central California UNIX Users 
Group consists of a wwcp-based electronic mailing 
list to which members may post questions or infor¬ 
mation. For connection information: 

Educational and governmental institutions: 

Brent Auemheimer (209) 294-4373 

CSNET: brent@CSUFresno.edu 
uucp: csufreslbrent 

Commercial institutions or individuals: 

Gordon Crumal (209) 435-6062 

uucp: csufres!tower!gordon 

CA - Los Angeles: the Los Angeles UNIX Group 
meets on the 3 rd Thursday of each month in 
Redondo Beach. 

Drew Bullard (213) 535-1980 

{ucbvax,ihnp4}! t rwrblbullard 

Marc Ries' (213) 535-1980 

{decvax,sdcrdcf} !trwrb!ries 

CO - Boulder: meets monthly at different sites. 

Front Range UNIX Users Group 
USENIX Association Exhibit Office 
5398 Manhattan Circle 
Boulder, CO 80303 

John L. Donnelly (303) 499-2600 

{boulder,usenix}!johnd 

FL - Coral Springs: 

S. Shaw McQuinn (305) 344-8686 

8557 W. Sample Road 
Coral Springs, FL 33065 

FL - Melbourne: the Space Coast UNIX Users 
Group meets at 8pm on the 3 rd Wednesday of each 
month at the Florida Institute of Technology. 

Alex Stover (305) 724-3962 

codas!lola!als 

Bill Davis (305) 242-4449 

bill@ccd.harris.com 


FL - Orlando: the Central Florida UNIX Users 
Group meets the 3 rd Thursday of each month. 


Mike Geldner 
codas!sunfla!mike 

(305) 862-0949 

Ben Goldfarb 
goldfarb@hcx9.ucf.edu 

(305) 275-2790 

Mikel Manitius 
{codas,attmail} Imikel 

(305) 869-2462 

GA - Atlanta: meets on the 1 st Monday of each 
month in White Hall, Emory University. 

Atlanta UNIX Users Group 

P.O. Box 12241 

Atlanta, GA 30355-2241 

Marc Merlin 

Mark Landry 

(404) 442-4772 
(404) 365-8108 

MI - Detroit/Ann Arbor: meets 
of each month in Ann Arbor. 

the 2 nd Thursday 

William Bulley 
web@applga.uucp 

(313) 995-6211 

Rich McGill 
rich@oxtrap.uucp 

(313) 971-5950 

Steve Simmons 
scs@lokkur.uucp 

(313) 426-8981 

MI - Detroit/Ann Arbor: dinner 
Wednesday of each month. 

meetings the 1 st 

Linda Mason 
michigan!/usr/group 

P.O. Box 189602 

Farmington Hills, MI 48018-9602 

(313) 855-4220 

MN - Minnetonka: meets the 
each month. 

1 st Wednesday of 

UNIX Users of Minnesota 

4732 Spring Circle 

Minnetonka, MN 55343 

Mark Colburn 
mark@ems.mn.org 
ihnp4! meccts! ems! mark 

(612) 935-2688 
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MO - St. Louis: 

St. Louis UNIX Users Group 
Plus Five Computer Services 
765 Westwood, 10A 
Clayton, MO 63105 


Eric Kiebler 
ihnp4!plus5!sluug 

(314) 725-9492 

NE - Omaha: meets on the 2 nd Thursday of each 
month. 

/usr/group nebraska 

P.O. Box 44112 

Omaha, NE 68144 

Sukan Makmuri 
ihnp4!ugn!root 

(402) 422-8367 

New England - Northern: meets 

different sites. 

monthly at 

Emily Bryant 

Kiewit Computation Center 
Dartmouth College 

Hanover, NH 03755 

(603) 646-2999 

David Marston 

Daniel Webster College 

University Drive 

Nashua, NH 03063 

(603) 883-3556 

decvaxldartvaxlnneuug-contact 


NJ - Princeton: the Princeton UNIX Users Group 
meets monthly. 

Pat Parseghian 

Dept, of Computer Science 

Princeton University 

Princeton, NJ 08544 

(609) 452-6261 

pep@Princeton.EDU 


NY - New York City: 

Unigroup of New York 

G.P.O. Box 1931 

New York, NY 10116 


Ed Taylor 

{attunix,philabs)!pencom!taylor 

(212) 513-7777 


New Zealand: 

New Zealand UNIX Systems User Group 
P.O. Box 13056 
University of Waikato 
Hamilton, New Zealand 


OK - Tulsa: 

Pete Rourke 
$USR 

7340 East 25 th Place 
Tulsa, OK 74129 


PA - Philadelphia: the UNIX SIG of the 
Philadelphia Area Computer Society (PACS) meets 
the morning of the 3rd Saturday of each month at 
the Holroyd Science Building, LaSalle University. 

G. Baun, UNIX SIG 
c/o PACS 
Box 312 

La Salle University 
Philadelphia, PA 19141 

{inhp4,cbosgd,rutgers}! {bpa,cbmvax}! 
temvax!pacsbb!{gbaun,whutchi} 


TX - Dallas/Fort Worth: 

Dallas/Fort Worth UNIX Users Group 
Seny Systems, Inc. 

5327 N. Central, #320 
Dallas, TX 75205 

Jim Hummel (214) 522-2324 


TX - San Antonio: the San Antonio UNIX Users 
(SATUU) meets the 3 rd Wednesday of each month. 

William T. Blessum, M.D. 12) 692-0977 

7950 Floyd Curl Dr. #102 
San Antonio, TX 78229-3955 
{gatech,ihnp4}!petro!bles!wtb 

The local uucp network “postmaster” is: 

Bruce Andreen (512) 656-3053 

(gatech,ihnp4) !petro!bruce 


WA - Seattle: meets monthly. 

Bill Campbell (206) 232-4164 

Seattle UNIX Group Membership Information 
6641 East Mercer Way 
Mercer Island, WA 98040 

uw-beaver! tikal! cameo !bill 


Washington, D.C.: meets the l sl Tuesday of each 
month. 

Washington Area UNIX Users Group 
2070 Chain Bridge Road, Suite 333 
Vienna, VA 22180 

Samuel Samalin (703) 448-1908 
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USENIX Association 

P.O. Box 2299 
Berkeley, CA 94710 


First Class Mail 


FIRST CLASS MAIL 
U.S. POSTAGE PAID 
Berkeley, CA 
Permit No. 993 


Election Results 
Conferences and Workshops 

5 th Annual Computer GO Tournament 
LOCK/ix Paper 

Update on UNIX Standards Activities 
Financial Statements 

Change of Address Form 

Please fill out and send the following form through the U.S. mail to the Association Office at the address above. 

Name:_Member #:_ 

OLD:___ NEW:___ 

Phone:_ 


uucp\ {uunet.ucbvax}! 





